-
Notifications
You must be signed in to change notification settings - Fork 120
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update callbackquery.go #141
Conversation
bcncalling
commented
Feb 15, 2024
•
edited
Loading
edited
- Added error logging in HandleUpdate function.
- Refactored Name method to generate a more unique name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi, thank you for your contribution!
I have to admit I'm not sure what the goal of this PR is - you seem to have opened this up without any prior discussion or context, so I can't tell what you're trying to achieve.
As it stands, the only part that I think should be merged would be the change to the callbackquery name, which you've correctly identified as being wrong. Could you update the PR to only include that change please? Thank you :)
@@ -11,27 +12,31 @@ import ( | |||
type CallbackQuery struct { | |||
AllowChannel bool | |||
Filter filters.CallbackQuery | |||
Response Response |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the reasoning behind this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the signature (b *gotgbot.Bot, ctx *ext.Context) error, allowing for greater versatility in defining response behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is the same signature as the existing Response
type... This is a noop and completely unnecessary change.
The definition is already: type Response func(b *gotgbot.Bot, ctx *ext.Context) error
func NewCallback(filter filters.CallbackQuery, r Response) CallbackQuery { | ||
return CallbackQuery{ | ||
func NewCallback(filter filters.CallbackQuery, response func(b *gotgbot.Bot, ctx *ext.Context) error) *CallbackQuery { | ||
return &CallbackQuery{ | ||
Filter: filter, | ||
Response: r, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please avoid unnecessary changes like this one (especially given there is no explanation provided)
// SetAllowChannel Enables channel messages for this handler. | ||
func (cb CallbackQuery) SetAllowChannel(allow bool) CallbackQuery { | ||
// SetAllowChannel enables channel messages for this handler. | ||
func (cb *CallbackQuery) SetAllowChannel(allow bool) *CallbackQuery { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we changing to a pointer reference here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changing the receiver from CallbackQuery to *CallbackQuery in the SetAllowChannel method allows the method to modify the CallbackQuery struct directly, rather than working with a copy of the struct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand the function of the change, but this doesnt explain the why.
Currently, SetAllowChannel copies the receiver and returns it, allowing for immutable chaining of methods. Changing it to be a pointer would break the immutability and introduce side effects to the method, which would then be inconsistent with all other handlers.
err := cb.Response(b, ctx) | ||
if err != nil { | ||
log.Printf("Error handling callback query: %v", err) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why should the callbackquery handler log errors, when none of the others do?
I'm not a fan of this pattern - I think people should add an error handler to the dispatcher, to ensure all errors are logged properly. Alternatively, they can also wrap the callbackquery handler to log just errors if necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's indeed a matter of design preference and code organization. Logging errors within the callback query handler can clutter the handler's logic and may not be the best approach for all situations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not a matter of "preference", it is a matter of consistency and configurability.
This change introduces a new logging paradigm which is inconsistent with all other handlers. Additionally, it cannot be configured (eg, to use JSON logging over text logging, to silence certain errors but allow others, or even to assign warn/error levels). All of these things are already possible when using the dispatcher-level error handling logic.
Ultimately, these are large changes which should be discussed over an issue, or in the support group, before being opened in a PR without any context. I don't like having to close PRs that people have worked on without discussion, because I hate to see work go to waste - so please make sure to discuss these things first.
func (cb CallbackQuery) Name() string { | ||
return fmt.Sprintf("inlinequery_%p", cb.Response) | ||
func (cb *CallbackQuery) Name() string { | ||
return fmt.Sprintf("callback_query_handler_%p", cb.Response) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch here, thanks for finding it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok i will pr this seperate by in the evening due to iam in college now
Closing due to being superseded by #144 |